[레포트] 랜딩존 구현의 핵심, AWS의 컨트롤 타워

세션

Agenda

• 클라우드 세상의 컨트롤 타워
• AWS Control Tower의 주요 기능
• 컨트롤 타워 전환 모범 사례
• AFT (Account Factory for Terraform) 의 활용

클라우드 세상의 컨트롤 타워

• 클라우드를 잘 쓰기 위해서는 고려애햐 할 사항이 많음
• 성능, 보안, 안정성 등은 기본이고 가격 경쟁력이나 지속 가능성까지도 고려해야함
• 비즈니스의 성장과 함께 이러한 요소들에 대한 고민이 많아질수록,  기초가 탄탄한 아키텍처 기반이 중요함을 실감하게 됨
• 그래서 랜딩존이 필요함

• 랜딩존의 개념적인 의미는 모레 밭이 아닌 탄탄하고 안전한 착륙 지점으로 볼 수 있음
• 클라우드에서의 사전적 의미는 아키텍처 모범사례의 보안적으로 안전하게 사전 정의된
• 클라우드 사용 환경 또는 학장 가능하고 유연한 아키텍처 설계를 위한 시작점 등으로 정의할 수 있음

• 랜딩존은 앞서 말한 것 처럼 잘 만들어진 아키텍처 컨셉 또는 패던임 AWS Landing Zone은 바로 AWS 환경에서 랜딩 존 컨셉을 구현할 수 있는 솔루션이고, AWS Control Tower는 AWS 랜딩존 솔루션을 고객들이 쉽게 사용할 수 있도록 서비스화 한 상품임

• 기존 랜딩존 솔루션에 비해, AWS Control의 시작은 매우 간단함
• AWS 콘솔에서 Setup landing zone 버튼만 누르면 됨
• 컨트롤 타워 설치에 문제가 없는지 자동화된 진단 후 설치가 진행 되며 약 한 시간 이내로 기본 구성이 완료됨

• 설치가 완료되면 AWS 환경에 이러한 기본 구성 랜딩 영역이 만들어짐
• 먼저 AWS Control Tower를 관리하는 Management 계정에 AWS Service Catalog 라는 서비스를 통해 Account Factory가 구성 됨
• Account Factory는 계정 생성 과정을 셀프 서비스로 자동화 하는 컨트롤 타워의 핵심 요소
• 그리고 AWS Organizations는 AWS 환경에서 다중 계정 환경을 관리하기 위한 것으로 OU 즉 Organization Units 이란 단위로 조직 구조를 설계할 수 있음
• 여기서 중요한 것은 OU의 단위는 서비스 제어 정책, 즉 Service Control Policy와 같은 조직 별 정책이 각각 적용되는 단위임
• 다수의 아카운트의 자격 증명 관리를 위한 AWS Single Sign-On 서비스도 기본적으로 통합되어 제공이 됨
• 다음으로 컨트롤 타워의 보안 감사 로그를 통합 저장하는 Log Archive 아카운트가 있고, 수 많은 ㄱ정들의 접근 로그와 같은 audit 정보들을 한곳에 모으는 역할을 함
• audit 아카운트는 security 및 compliance 감사 목적으로 상요되는 제한된 계정임 각 아카운트에는 Account Baseline이 설정된 것을 볼 수 있는데, 아카운트가 기본적으로 가지게 되는 속성을 사전에 정의해두면 Account Factory가 아카운트 생성 시점에서 자동으로 설정해 주는 개념임
• 결국 컨트롤 타워를 설치하고 나면 고객 환경에 맞는 OU 구조와 정책을 설계하고 Account Baseline 또는 Network Baseline을 환경에 맞게 잡아 나가는 것이 다음 스탭이 됨

AWS Control Tower의 주요 기능

• 이제 AWS Control Tower의 주요 기능들을 소개
• 랜딩존의 기본 요소들을 자동으로 설치해 주는 것 외에 AWS 모범 사례를 기반으로 한 가드레일 적용 아카운트 팩토리, 대시보드를 포함하여 AWS IAM 등 AWS 서비스들과의 연계, 사전 정의된 감사 로그, 모니터링 및 얼러팅 기능, AWS Marketplace를 통한 솔루션 확장 기능 등을 주요 기능으로 꼽을 수 있음
• 이 중 가장 핵심 개념이라고 할 수 있는 가드레일과 아카운트 팩토리에 대해 이야기 하고자 함

• 가드레일이란 개념은 클라우드의 거버넌스에서 중요한 개념
• 가드레일이라는 규칙의 경계 안에서는 최대한의 자유를 보장해 준다는 개념
• 컨트롤 타워에서의 가드레일은 다음과 같이 일반적인 언어로 표현이 되고, 크게 다음 두 가지로 나눠볼 수 있음
• 먼저 예방 가드레일은 항상 지켜야 하는 규칙임
• 예를 들어 클라우드 사용 기록들을 담고 있는 AWS CloudTrail의 설정 변경을 금지하는 문구임
• 그리고 탐지 가드레일은 반드시 지켜야 하는 규칙은 아니지만, 규칙을 어겼을 때 위반 사실을 알려 주겠다는 것
• 예를 들면 감사 로그가 저장되는 S3 버킷이 외부로 공개되어 있는지 여부를 확인하는 경우임

• 예방 가드레일은 SCP(Service Control Policy)라고 하는 강력한 정책을 통해 규칙을 항상 준수하도록 하고 탐지 가드레일은 Config Rule을 통해 규정 준수를 권고하고, 준수 여부를 확인할 수 있음
• 실제 컨트롤 타워 대시보드를 통해 각각의 가드레일 세부 내용과 적용 여부를 확인 가능하고, 가드레일은 계속해서 업데이트가 됨

• 예를 들어 작년 말에는 Data Residency라는 카테고리가 새롭게 추가 되었음
• Data Residency는 데이터 주권, 데이터 상주로 정의할 수 있음
• 데이터가 저장되고 처리되는 물리적 위치가 법적으로 또는 컴플라이언스 차원에서 중요한, 금융권이나 공공 기관과 같은
  영역에서 매우 중요한 요소임
• 기존에 이러한 요구사항을 적용하기 위해 복잡한 규칙을 직접 구현해야만 했음

• 이제는 컨트롤 타워를 통해 너무나도 쉽게 정책을 적용할 수 있음
• 다중 리전과 다중 계정에 대해서도 어려움 없이 일관된 정책을 적용 가능

• 아카운트 팩토리는 컨트롤 타워의 가장 중요한 요소 중 하나로, 말 그대로 다중 계정을 생성하는 기능임
• 새로운 계정을 생성하고 조직의 요구사항에 꼭 맞게 설정하는 과정은 간단하지 않음
• 이러한 과정을 아카운트 팩토리를 통해 자동화하고 표준화할 수 있음

• 아카운트 팩토리는 AWS Service Catalog라는 서비스를 통해 작동하기 때문에 Service Catalog에 대해서도 좀 더 알아보고 가겠음
• 좌측에 클라우드 팀이라고 표현된 조직의 관심사는 일반적으로 거버넌스, 보안, 통제라고 볼 수 있음
• 반면에 우측에 개발팀 조직의 관심사는 Agility, 셀프서비스, Time to market 비즈니스 혁신과 같은 키워드로 볼 수 있음
• 이 두 조직의 관심사가 충돌하는 바로 중간 지점에 컨트롤 타워가 있고 이를 가능하게 해 주는 서비스가 Service Catalog임

• 아카운트 팩토리에서 미리 사전 정의된 baseline들을 카탈로그처럼 만들어 두면, 사용자는 새로운 아카운트가 필요할 때마다  셀프서비스로 아카운트 생성을 자동화할 수 있게 됨
• 이를 통해 생성되는 아카운트에는 자동으로 가드레일이 적용되고 요구사항에 꼭 맞는 baseline도 가질 수 있는 것임

• 컨트롤 타워는 기본적으로 대시 보드를 제공하고, 현재 관리되고 있는 조직과 아카운트, 리소스들의 정책 준수 여부도 한눈에 확인이 가능
• 컨트롤 타워는 수 많은 AWS 서비스들과 연계되어 범위를 확장할 수 있음

• 특히 AWS 보안 서비스 들과 밀접히 통합되어 있기 때문에 컨트롤 타워 토입 시점에 클라우드 전반의 보안 아키텍처를 탄탄히 잡고 갈 수 있음

컨트롤 타워 전환 모범 사례

• 각각의 케이스에 대해 특징과 고려사항을 정리
• 첫 번째로, 가장 쉬운 케이스
• 컨트롤 타워를 최초로 도입하는 경우
• 가장 빠르고 쉽게 시작 가능한 방법으로, 버틈나 클릭하면 자동화된 사전 진단 및 구성으로 약 한 시간 내로 AWS 베스트 프랙티스 아키텍처 기반을 마련할 수 있음
• 고객에게는 모범 사례로 구성된 안전한 아키텍처 기반 위에서 어떻게 비즈니스를 빠르게 확장하고 혁신할지를 고민하면 됨

• 어느 정도 비즈니스 규모가 되는 엔터프라이즈의 경우 이미 다중 계정 관리를 위해 AWS Organizations를 사용하고 있을 것
• 이러한 경우 컨트롤 타워로 전환하는데 컨트롤 타워가 설치되는 Organizations를 기존 조직 형태로 유지할 것인지, 아니면 새로운 조직으로 구성할 것인지 결정해야 함
• 기존 조직에 컨트롤 타워를 설치하는 경우 일반적으로 문제가 없지만 만약 회사의 인수 / 합병 등의 사유로 새로운 Organizations로 구성해야 하는 경우에는 payer 계정이 변경되는 점과 기존 관리 계정의 정책 및 워크로드 이관이 어렵다는 점을 참고

• 첫 번째로, 기존 랜딩존에서 생성된 리소스들의 의존성 파악
• 컨트롤 타워 전환이 쉽나 어렵나를 이야기할 때 가장 중요한 부분
• Account vending machine 이벤트에 연계된 프로세스나, 3rd party 통과의 연계 등 기존 랜딩존 환경에서 intergration된 부분과 커스텀 리소스들의 변경 영향도를 정확히 파악하는 것이 필수이기 때문
• 다음으로는, 컨트롤 타워를 어떤 OU에 구성할 것인가
• 기존 랜딩존과 동일한 OU를 그대로 유지하는 경우, 기존 SCP 정책을 그대로 승계하므로 컨트롤 타워에서 OU 단위 등록만 하면 이관이 된다는 편리함이 있지만 동일한 OU 내에 기존 랜딩존 정책과 신규 컨트롤 타워 정책들이 혼재될 수 있으므로, 경우에 따라 마이그레이션 과정이 복잡해 질 수 있는 것이 단점
• 반면에 신규 OU에 컨트롤 타워를 구성하는 경우, 컨트롤 타워 영역으로 기존 아카운트들을 OU 단위 또는 Account 단위로 등록이 필요함. 이 경우 정책 마이그레이션 과정에 기존 OU에 연계된 정책만 명확히 파악하고 있다면 마이그레이션이 좀 더 단순하다는 장점이 있음
• 기존 랜딩존이 관리하던 OU나 아카운트를 새로운 컨트롤 타워 관리 영역으로 넣는 과정을 Enroll 한다고 함
• OU단위 또는 아카운트 단위로 수행할 수 있음
• Enroll 과정에서 아카운트 베이스라인을 구성하는데, 약 한 시간가량 소요되기 때문에 다수의 계정을 Enroll 해야 하는 경우 마이그레이션 소요 시간도 중요한 고려 대상이 될 수 있음
• 상용 계정으로 마이그레이션 하기 전에 각 시나리오 별 충분한 검증 및 테스트 역시 중요한 부분
• 테스트 대상으로 enrollment 과정, 가드레일, 커스텀 정책 검증 및 Security 서비스 전환, S3 버킷 마이그레이션 등의 검증 테스트 등을 포함함
• 현 시점을 기준으로 컨트롤 타워를 지원하는 리전 개수는 총 15개 리전임
• 지원 리전의 수는 지속적으로 확장중이지만, 다양한 글로벌 리전에서 서비스를 운영하고 있는 고객의 경우 참고하면 좋을 것 같음

• Terraform Landing Zone 같은 오픈 소스나 별도 솔루션을 통해 랜딩존 컨셉을 구성하여 사용하는 경우, 기능적으로나 관리적으로 많은 어려움이 있음
• 관리형 서비스인 컨트롤 타워로 전환하는 것을 추천
• 이때 기존에 관리 중인 커스텀 정책을 컨트롤 타워로 마이그레이션 하는 부분이 핵심이고, 이 때 CfCT 즉 Customizations for Control Tower나, AFT 같은 툴을 사용하여 전환하는 것이 좋음

• 먼저 사전 준비과정을 거쳐 마이그레이션 방향성을 결정 후 컨트롤 타워를 설치하고, 마이그레이션 단계에서 계정이나 리소스들을 이관하는 과정을 거치게 되면 고객 상황에 꼭 맞는 환경 구성을 위해 추가적으로 CfCT나 AFT를 이용하여 정책을 최적화 하거나, 네트워크, 보안 서비스 들로 확장해 나가게 됨

AFT (Account Factory for Terraform) 의 활용

• AFT는 아카운트 생성 및 사용자 정의 환경을 배포하는 테라폼 기반의 파이프라인임
• 기존에 컨트롤 타워에서 아카운트 팩토리와 CfCT라는 솔루션으로 기능이 이원화되어 있던 부분을 AFT만으로 구현할 수 있고, 특히 아카운트 생성 과정 및 customization 파이프라인 자체를 사용자가 직접 정의할 수 있는 확장성과 유연성을 제공함

• AFT 아키텍처는 AFT 파이프라인 자체를 정의한 모듈과, 선택적으로 삽입 가능한 확장 모듈들을 on/off 스위치처럼 적용할 수 있는 기능의 AFT Feature options, customization 모듈로 구분해 볼 수 있음

• 사용자가 AFT의 아카운트 생성 요청 파이프라인을 시작하게 되면 공통 customization, 개별 아카운트 customization 순서로 진행되며 아카운트 생성 및 커스텀 구성 작업을 진행함
• 이때 이 파이프라인 과정 자체를 사용자가 직접 컨트롤할 수 있도록 해 주는 요소가 Account provisioning customizations 모듈임

• AFT 파이프라인 전체 과정을 도식화해 보면 아카운트 생성부터 커스텀 작업까지 전 과정을 별도의 AFT 관리 계정에서 테라폼 모듈로 직접 핸들링 한다는 것을 알 수 있음

참고

본 블로그에서 사용한 이미지는 AWS Summit Korea에서 제공된 발표자료와 영상을 사용했습니다.